1. Architectures des dossiers en Symfony 4/5
Voilà un topic sur le sujet :
https://stackoverflow.com/questions/47594542/symfony-4-how-to-organize-folder-structure-namely-your-business-logic
Deux solutions sortent du lot avec des arguments différents.
1.1 Solution 1
-src
- Controller
- Core
- Todos
- ...
- Entity
- Core
- Todos
- ...
- Repository
- Core
- Todos
- Validator (or other Symfony oriented components)
- Core
- Todos
- Others (depend on project)
- Core
- Todos
L'avantage d'une telle arborescence est de retrouver toutes les implémentations d'une certaine catégorie dans un dossier principal.
Le problème est par contre le suivant : si on souhaite supprimer une fonctionnalité, il faut supprimer dans chaque dossier les fichiers qui concernent la fonctionnalité, on ne distingue pas un découpage simple des différents domaines de l'application.
1.2 Solution 2
├─ assets/
├─ bin/
│ └─ console
├─ config/
│ ├─ doctrine/
│ │ ├─ core/
│ │ └─ sample/
│ ├─ packages/
│ ├─ routes/
│ └─ validator/
│ │ ├─ core/
│ │ └─ sample/
├─ public/
│ └─ index.php
├─ src/
│ ├─ Core/
│ │ ├─ Controller/
│ │ ├─ Entity/
│ │ ├─ Repository/
│ │ └─ ...
│ ├─ Sample/
│ └─ ...
├─ templates/
│ ├─ core/
│ └─ sample/
├─ tests/
├─ translations/
├─ var/
│ ├─ cache/
│ ├─ log/
│ └─ ...
└─ vendor/
L'avantage d'une telle solution est qu'il est plus simple de retrouver tous les fichiers qui concernent une fonctionnalité. Par contre la configuration peut être plus compliquée ; dans le cas de doctrine, il ne suffit plus de dire que toutes les classes d'entités sont dans src/Entity/*(/*), mais plutôt dans src/*/Entity/*(/*).
🧙♂️️Je préfère cette solution-ci qui permet d'avoir un lien simple entre une url /domain et un dossier src/Domain.
2. Projet monolithique
Attention : ici, je distingue un projet monolithique et une application monolithique.
Le projet est pour moi l'ensemble des fichiers que les développeurs manipulent pour construire toutes les applications.
Chaque application ne doit être déployée qu'avec son code source.
Qu'est ce qu'il est plus simple : gérer dans son équipe un projet par application ou un repository git (qui peut être un composite de plusieurs .git) pour toutes les applications ?
La réponse semble évidente, et pourtant on a tendance à se dire que chaque application doit avoir son propre repository.
Alors, éventuellement, il est possible de configurer son IDE pour intégrer plusieurs repository .git
Voilà à quoi pourrait ressembler un projet contenant plusieurs applications :
application_[n]
/src
/config
/routes
/templates
/var
/cache
/log
/vendor
composer.json
core
/config
/domains
/Common
/Infrastructure
/Doctrine
/RabbitMq
/Elasticsearch
/Service
/Utility
/Domain_[n]
/Enumeration
/Helper
/Infrastructure
/Model
/Service
/Utility
/vendor
/composer.json
A noter que,
* l'utilisation du framework est liée à une application, cette application peut être native PHP ou non ;
* tout ce qui se trouve dans le dossier 'core' est frameworkless, c'est à dire que le code ne devrait pas dépendre d'un framework ou d'un composant tier (vendor) ; ce qui est potentiellement difficile à respecter.
Ce qui veut dire qu'il est possible, sous réserve évidemment que le framework/CMS tourne sous la même version de PHP que le code, de travailler sur plusieurs applications en gardant un espace propre à son métier (dossier core).
Il est possible d'avoir un .git au niveau de chaque application et d'avoir un gestionnaire de version de cette forme :
-company/application_1
-company/application_2
-company/application_3
-company/core
Bien sûr, si vos applications mélangent plusieurs technologies (ex: PHP/NodeJs/J2E), il faudra peut-être éventuellement avoir autant d'espaces de travail distincts.